Virtual file system

ABSTRACT

A virtual file system is provided. Results are received of a first search for files related to current context of a user of the virtual file system, the files being stored on physical media and/or other virtual file systems. The results of the first search are organized into contextually significant virtual folders of the virtual file system. A first entry is recorded into a history of path mappings which map location of the files in the virtual folders to locations of the files on the physical media. Results are received of a second search for files related to an updated context of the user of the virtual file system. The organization of contextually significant virtual folders is updated based on the results of the second search, and a second entry is recorded into the history of path mappings based on the updated organization.

FIELD

The present disclosure relates to a virtual file system, and moreparticularly relates to organizing and updating a virtual file system.

BACKGROUND

In the field of file management, it is common to provide a virtual filesystem. A virtual file system is an abstract interface to another filesystem or systems. For example, a virtual file system may provide aninterface for client applications to access physical files at multipledifferent physical locations.

SUMMARY

One difficulty with conventional virtual file systems is that locatingfiles requires search queries to be made to each system individually asrequested, making the search process time consuming. This problem isexacerbated with the growing popularity of cloud storage systems, as thenumber of repositories for files continues to grow. Moreover, because ofthe scale of such storage, it is often difficult for users to findrelevant documents. For example, a virtual file system may representthousands (or millions) of files in hundreds of places, withoutproviding any insight to the user as to how to reach desired or relevantfiles, much less to account for changing locations or information ofsuch files over time (i.e., if a file is saved in a different location).

The foregoing situation is addressed by providing a virtual file systemwhich generates and updates virtual files and directories based oncurrent context of a user, while maintaining updated mappings to thecorresponding physical files. A current context of the user may, forexample, refer to user behavior such as applications, files or foldersopened by the user, or search terms entered by the user or the order inwhich a user accesses files. Moreover, searching for files and foldersrelated to the current context of the user is performed continuously andautomatically.

Thus, in an example embodiment described herein relative to a virtualfile system, results are received of a first search for files related tocurrent context of a user of the virtual file system, the files beingstored on physical media and/or other virtual file systems. The resultsof the first search are organized into contextually significant virtualfolders of the virtual file system. A first entry is recorded into ahistory of path mappings which map location of the files in the virtualfolders to locations of the files on the physical media. Results arereceived of a second search for files related to an updated context ofthe user of the virtual file system. The organization of contextuallysignificant virtual folders is updated based on the results of thesecond search, and a second entry is recorded into the history of pathmappings based on the updated organization.

In one aspect, the current context of the user includes at least systemstate and at least user behavior correlated over time. For example, thesystem state may include applications, files or folders opened by theuser. The current context of the user may also include search termsentered by the user or the order in which a user accesses files.

By providing a virtual file system which generates and updates virtualfiles and directories based on current context of a user whilemaintaining updated mappings to the corresponding physical files, it isordinarily possible to improve the user experience by recommending orproviding relevant virtual directories and files, while at the same timeallowing faster access to the corresponding physical files.

In one example aspect, a request is received to open a selected filefrom a virtual folder, and the path of the selected file is resolved toa physical location of a target file on a physical medium, by referenceto an entry in the recorded history of path mappings corresponding to atime when the file open request was received.

In another example aspect, an open-close cycle for a file is addressed.Based on the virtual file system, a target file is opened from thephysical location on the physical medium. A request is thereafterreceived to close the opened file. The path of the opened file isresolved to a physical location of a target file on a physical medium byreference to the entry in the recorded history of path mappingscorresponding to a time when the file open request was received, and thetarget file is closed. In one aspect, closing the target file includesupdating the target file with changes made to the opened file.

In another example aspect, each entry in the history of path mappingsfurther includes at least content of opened files, virtual folderstructure, and metadata of files in the virtual folders.

In one example aspect, the second search is triggered by a change incurrent context of the user of the virtual file system that exceeds apredetermined threshold. In another example aspect, the second search istriggered periodically after an elapse of a predetermined interval. Instill another example aspect, the second search is triggered by thefirst to occur of a change in current context of the user of the virtualfile system that exceeds a predetermined threshold and an elapse of apredetermined interval.

In another example embodiment described herein relative to a virtualfile system, current context of a user of the virtual file system ismonitored. The current context of the user includes at least systemstate and at least user behavior correlated over time. Files stored onphysical media and/or other virtual file systems and related to acurrent context of the user of the virtual file system are searched for.The results of the search are organized into contextually significantvirtual folders in the virtual file system. The virtual folders aredisplayed for manipulation by the user of the virtual file system.

By monitoring a current context of a user and providing contextuallysignificant virtual folders, it is ordinarily possible to providerelevant file and folder suggestions to a user, and to thereby increasethe user's efficiency and convenience.

In one example aspect, the search is performed across multiple remoterepositories of physical media. In a further example aspect, a cache ismaintained. The cache stores copies of physical files listed in thevirtual folders linked to virtual paths for the virtual folders.

In another example aspect, the search is triggered by a change incurrent context of the user of the virtual file system that exceeds apredetermined threshold. In another example aspect, the search istriggered periodically after an elapse of a predetermined interval. Instill another example aspect, the search is triggered by the first tooccur of a change in current context of the user of the virtual filesystem that exceeds a predetermined threshold and an elapse of apredetermined interval.

In another example embodiment described herein relative to a virtualfile system, results are received of a first search for files related toa current context of a user of the virtual file system, the files beingstored on physical media and/or other virtual file systems. The resultsof the first search are organized into contextually significant virtualfolders in the virtual file system. Responsive to selection of a virtualfolder in the virtual file system, a list of files organized in theselected virtual folder according to the first search is displayed.Responsive to selection of a root directory in the virtual file system,results are obtained of a second search for files related to an updatedcontext of the user of the virtual file system, the organization ofcontextually significant virtual folders is updated, and the updatedorganization of virtual folders is displayed.

By treating root directories differently in the virtual file system, itis ordinarily possible to incorporate file or folder suggestions to theuser based on the root directory, while allowing the remaining virtualdirectories to map to actual file(s) on physical media and/or othervirtual file systems.

In one example aspect, responsive to selection of a virtual folder, pathmappings are resolved, of physical locations on the physical media tovirtual files in the selected virtual folder, and a list is retrieved ofvirtual files and virtual folders contained in the selected virtualfolder.

In another example aspect, a request is received to open a selected filelisted in a virtual folder. The contents of the virtual file aremodified to add application-level attributes including information formapping of the virtual file to a physical location on a physical medium,and the modified file is opened. In yet another example aspect, arequest is received to close the opened file. The application-levelattributes added to the virtual file are extracted, including thephysical path. The target file mapped by the path mapping is updated soas to include updates to the opened virtual file, and the virtual fileis closed.

In one example aspect, the second search is also triggered by a changein current context of the user of the virtual file system that exceeds apredetermined threshold. In another example aspect, the second search isalso triggered periodically after an elapse of a predetermined interval.In still another example aspect, the second search is also triggered bythe first to occur of a change in current context of the user of thevirtual file system that exceeds a predetermined threshold and an elapseof a predetermined interval.

This brief summary has been provided so that the nature of thisdisclosure may be understood quickly. A more complete understanding canbe obtained by reference to the following detailed description and tothe attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example environment in which aspects of thepresent disclosure may be practiced.

FIG. 2 is a detailed block diagram depicting an example of the internalarchitecture of each of the computers shown in FIG. 1 according to anexample embodiment.

FIG. 3 illustrates a virtual file system module according to an exampleembodiment.

FIG. 4 depicts a context management file system driver for implementinga virtual file system according to an example embodiment.

FIG. 5A is a flow diagram illustrating a process for adding one or morefiles to a virtual drive which are related to user actions. FIG. 5B is aview for illustrating the process for adding one or more files to avirtual drive.

FIG. 6, comprising FIG. 6A and FIG. 6B, is a block diagram illustratingan example system architecture for a virtual file system according to anexample embodiment.

FIG. 7 is a flow diagram for explaining access to root and non-rootdirectories according to an example embodiment.

FIG. 8 is a flow diagram for explaining a virtual file system dataaccess/read flow according to an example embodiment.

FIG. 9 is a flow diagram for explaining a virtual file system dataaccess/write flow according to an example embodiment.

DETAILED DESCRIPTION

As shown in FIG. 1, computers 50, 100, 150, 200 and 250 are computersconnected across a network. While five computers are shown in FIG. 1 forpurposes of simplicity, it should be understood that the number ofcomputers and/or devices on the network may be any number. Moreover,while FIG. 1 depicts a computers 50, 100, 150, 200 and 250 as desktopcomputers, it should be understood that computing equipment or devicesfor practicing aspects of the present disclosure can be implemented in avariety of embodiments, such as a laptop, mobile phone, ultra-mobilecomputer, portable media player, game console, personal device assistant(PDA), netbook, or set-top box, among many others.

Each of computers 50, 100, 150, 200 and 250 generally comprise aprogrammable general purpose personal computer having an operatingsystem, such as Microsoft® Windows® or Apple® Mac OS® or LINUX, andwhich is programmed as described below so as to perform particularfunctions and, in effect, become a special purpose computer whenperforming these functions.

Each of computers 50, 100, 150, 200 and 250 includes computer-readablememory media, such as fixed disk 45 (shown in FIG. 2), which isconstructed to store computer-readable information, such ascomputer-executable process steps or a computer-executable program forcausing the computer to perform a method for providing a virtual filesystem, as described more fully below.

As shown in FIG. 1, computer 100 presents a virtual file drive (N:\) ofa virtual file system to the user. The virtual file system/drivesimulates physical files stored on other repositories (e.g., computers50, 150, 200 and 250) as files which are stored and accessible locally.For example, as shown in FIG. 1, computer 150 is a shared-folderrepository, computer 200 is a SharePoint repository, and computer 250 isa local file system repository, but the files stored therein are shownvirtual file drive N:\ on computer 100 as if they were stored locally.Of course, other types and numbers of repositories are possible.

As a user performs actions on computer 100 such as entering search termsor opening files, the virtual file system described herein also performsan automatic search for related files and folders and displays them asshown in FIG. 1. Of course, the display in FIG. 1 is only an example,and numerous different types of display of files and folders arepossible.

Network 300 transmits data between computers 50, 100, 150, 200 and 250.The implementation, scale and hardware of network 300 may vary accordingto different embodiments. Thus, for example, network 300 could be theInternet, a Local Area Network (LAN), Wide Area Network (WAN),Metropolitan Area Network (MAN), or Personal Area Network (PAN), amongothers. Network 300 can be wired or wireless, and can be implemented,for example, as an Optical fiber, Ethernet, or Wireless LAN network. Inaddition, the network topology of network 300 may vary.

FIG. 2 is a detailed block diagram depicting an example of the internalarchitecture of computer 100 shown in FIG. 1 according to an exampleembodiment. For purposes of conciseness, only the internal architectureof computer 100 is described below, but it should be understood thatother computers 50, 150, 200 and 250 or other devices may includesimilar components, albeit perhaps with differing capabilities.

As shown in FIG. 2, computer 100 includes central processing unit (CPU)110 which interfaces with computer bus 114. Also interfacing withcomputer bus 114 are fixed disk 45 (e.g., a hard disk or othernonvolatile storage medium), network interface 111 for accessing otherdevices across network 300, keyboard interface 112, mouse interface 113,random access memory (RAM) 115 for use as a main run-time transientmemory, read only memory (ROM) 116, and display interface 117 for adisplay screen or other output.

RAM 115 interfaces with computer bus 114 so as to provide informationstored in RAM 115 to CPU 110 during execution of the instructions insoftware programs, such as an operating system, application programs,and device drivers. More specifically, CPU 110 first loadscomputer-executable process steps from fixed disk 45, or another storagedevice into a region of RAM 115. CPU 110 can then execute the storedprocess steps from RAM 115 in order to execute the loadedcomputer-executable process steps. Data, such as messages received onnetwork 300, or other information, can be stored in RAM 115 so that thedata can be accessed by CPU 110 during the execution of thecomputer-executable software programs, to the extent that such softwareprograms have a need to access and/or modify the data.

As also shown in FIG. 2, fixed disk 45 contains computer-executableprocess steps for operating system 118, and application programs 119,such as display programs. Fixed disk 45 also containscomputer-executable process steps for device drivers for softwareinterface to devices, such as input device drivers 120, output devicedrivers 121, and other device drivers 122. Other files 125 are availablefor output to output devices and for manipulation by applicationprograms.

Virtual file system module 123 comprises computer-executable processsteps for providing a virtual file system, and generally comprises areceiving/monitoring module, an organizing module, a search module, anupdating module and a display module. More specifically, virtual filesystem module 123 is configured to provide a virtual file system whichgenerates and updates virtual files and directories based on currentcontext of a user, while maintaining updated mappings to thecorresponding physical files. Moreover, virtual file system module 123is configured to monitor a current context of a user and providingcontextually significant virtual folders, to provide relevant file andfolder suggestions to a user. In addition, virtual file system module123 is configured to treat root directories differently in the virtualfile system, and to incorporate file or folder suggestions to the userbased on the root directory, while allowing the remaining virtualdirectories to map to actual file(s) on physical media and/or othervirtual file systems. Virtual file system module 123 may also store pathmappings 124, which includes a history of mappings from locations offiles in virtual file folders to locations of files on physical media.These processes will be described in more detail below.

The computer-executable process steps for virtual file system module 123may be configured as part of operating system 119, as part of an outputdevice driver, such as a router driver, or as a stand-alone applicationprogram. Collaborative network defense module 123 may also be configuredas a plug-in or dynamic link library (DLL) to the operating system,device driver or application program. It can be appreciated that thepresent disclosure is not limited to these embodiments and that thedisclosed modules may be used in other environments.

FIG. 3 illustrates a virtual file system module 123 according to anexample embodiment.

In particular, FIG. 3 illustrates an example architecture of virtualfile system module 123 in which the sub-modules of virtual file systemmodule 123 are included in fixed disk 45. Each of the sub-modules arecomputer-executable software code or process steps executable by aprocessor, such as CPU 110, and are stored on a computer-readablestorage medium, such as fixed disk 45 or RAM 115. More or less modulesmay be used, and other architectures are possible.

As shown in FIG. 3, virtual file system module 123 includesreceiving/monitoring module 301 for receiving results of a first searchfor files related to a current context of a user of the virtual filesystem, the files being stored on physical media and/or other virtualfile systems. Receiving/monitoring module 301 is also for monitoringcurrent context of a user of the virtual file system, wherein currentcontext of the user includes at least system state and at least userbehavior correlated over time. To that end, receiving/monitoring module301 communicates with network interface 11, keyboard interface 112, andmouse interface 113. Receiving/monitoring module 301 also receivesresults of a second search for files related to an updated context ofthe user of the virtual file system.

Receiving/monitoring module 301 also communicates with organizing module302, which is for organizing the results of a search (e.g., the resultsreceived from the first search mentioned above) into contextuallysignificant virtual folders of the virtual file system. Organizingmodule 302 also records a first entry into a history of path mappings(e.g., path mappings 124) which map location of the files in the virtualfolders to locations of the files on the physical media. Search module303 is for searching for files related to a current context of the userof the virtual file system, the files being stored on physical mediaand/or other virtual file systems. To that end, search module 303 isconnected to network interface 111. Updating module 304 is for updatingthe organization of contextually significant virtual folders based onthe results of the second search and recording a second entry into thehistory of path mappings based on the updated organization. Thus,updating module communicates with organizing module 302.

Display module 305 is for displaying the virtual folders formanipulation by the user of the virtual file system, and communicateswith display interface 117. Display module 305 may, responsive toselection of a virtual folder in the virtual file system, display a listof files organized in the selected virtual folder according to thesearch.

Responsive to selection of a root directory in the virtual file system,receiving/monitoring module 301 may also receive results of a secondsearch for files related to an updated context of the user of thevirtual file system, updating module 304 may update the organization ofcontextually significant virtual folders, and display module 305 maydisplay the updated organization of virtual folders. Each of theseprocesses will be described more fully below.

FIG. 4 depicts a context management (hereafter CXM) file system driver400 for implementing a virtual file system according to an exampleembodiment. In some example embodiments, aspects of CXM file systemdriver 400 may correspond to one or more aspects of virtual file systemmodule 123, and may be stored on, e.g., fixed disk 45.

Generally, CXM file system driver 400 simulates virtual files onmultiple different computers in a manner in which files on a local harddrive would appear. CXM file system driver 400 thus provides dynamicmapping to documents from a variety of sources, and adjusts for what maybe a constantly changing list of files based on the context search.

Thus, in one embodiment, current context of a user of the virtual filesystem is monitored. The current context of the user includes at leastsystem state and at least user behavior correlated over time. Filesstored on physical media and/or other virtual file systems and relatedto a current context of the user of the virtual file system are searchedfor. The results of the search are organized into contextuallysignificant virtual folders in the virtual file system. The virtualfolders are displayed for manipulation by the user of the virtual filesystem.

In one aspect, the search for files on physical media and/or othervirtual file systems and related to a current context of the user isperformed by context management services (hereafter CXM services).Example aspects of CXM services are described in U.S. patent applicationSer. No. 14/260,813, filed Apr. 24, 2014, entitled “Devices, Systems,and Methods for Context Management”, the contents of which areincorporated by reference herein.

In order to cluster the results, the X-mean algorithm can be used. TheX-means algorithm is similar to the k-means algorithm, except that itdetermines the k automatically. See, for example, Pelleg, et al.,“X-means: Extending K-means with Efficient Estimation of the Number ofClusters”, 2000. As input to the X-mean algorithm, a document termmatrix can be created, where each row is a keyword present in at leastone CXM result and each column contains the weight of that keyword asdetermined by CXM (or 0 if the term is not present). The X-meansalgorithm will run and divide the results into relevant sets ofdocuments. In one example, for each cluster, the keyword with thehighest weight for a cluster becomes the name of the correspondingfolder.

In one embodiment, a directory listing performed by CXM file systemdriver 400 provides the list of virtual files in a similar manner tophysical files stored locally. Thus, for example, the user may beprovided with a virtual file drive (N:\) and a list of folders and filesstored therein, as shown in FIG. 1. The directory listing is updatedautomatically with relevant files and folders to actions being performedby the user. In one aspect, the current context of the user includes atleast system state and at least user behavior correlated over time. Forexample, the system state may include applications, files or foldersopened by the user, and the current context of the user may includesearch terms entered by the user or the order in which a user accessesfiles.

CXM file system driver 400 also provides access to the physical filescorresponding to the virtual files in the virtual file system. Inparticular, for every listed file and directory in the directorylisting, corresponding virtual files and folders are created. Thevirtual files and folders are stored in cache 401 shown in FIG. 4, alongwith a mapping to the physical source file (generated by mapper 404).

In this regard, in some embodiments, a virtual file may comprise onlymetadata about the physical file and some parts of the physical file(e.g., the cached portions), with more parts of the file being obtainedfrom the physical file as needed. The metadata may include, for example,the location of the physical source file, along with other informationsuch as the last time the physical file was modified. Generally, onlyparts of the physical file are stored, because downloading and storingeach physical file in full would take up significant amounts of time andmemory. The virtual folders may comprise only metadata.

To access a physical file, CXM file system driver 400 refers to thevirtual file, which includes the data mapping to the source file. Inparticular, mapper 404 consults the metadata for the virtual file incache 401 to see where the actual physical file is located. The contentmay then be retrieved using repository connection services 402, whichperforms download/upload operations on various local and remoterepositories. Repositories can include cloud storage such as GoogleDrive, Amazon S3, Dropbox, etc., local file storage such as localdrives, USB drive, etc., and SharePoint and/or Network Shareddrives/folders.

Each of the modules in CXM file system driver 400 will now be describedin more detail.

Cache 401 is used to store data for mapper 404, as well as instances ofvirtual folder and virtual file objects, as discussed above. In oneembodiment, cache 401 also includes pieces of all files downloaded. Thisallows fast access for read/write/seek requests. In one example, cacheaccess to these files is performed using a unique ID associated witheach virtual folder and virtual file objects. Operations on any onespecific cache item may be atomic (e.g., access from multiple threads isqueued and performed one at a time).

The contents of cache 401 are determined by mapper 404, and the mapper404 can add files to the cache. Cache 401 is generally limited tovirtual files, folders and some parts of the physical file. Cache 401stores copies of physical files listed in the virtual folders linked tovirtual paths for the virtual folders.

Thus, for example, a user may instruct to open the virtual (N:\) drive.VFS local driver 406, as discussed below, obtains a root directorylisting, and documents for the root directory and relevant to thecurrent context of the system or user are searched for using CXMservices, and virtual files are created therefor and placed in cache401. In one example aspect, the search is performed across multipleremote repositories of physical media. In another example, searching forfiles and folders related to the current context is performedcontinuously and automatically, as discussed more fully below.

On the other hand, when a user instructs to open a sub-directory (i.e.not a root directory), repository connection services 402 obtains thephysical files corresponding to the virtual files and places them intothe cache 401. To that end, cache 401 may also store a mapping tablebetween physical and virtual files.

In more detail, a history of path mappings is maintained at cache 401 bymapper 404. For example, each entry in the history of path mappings mayinclude at least content of opened files, virtual folder structure, andmetadata of files in the virtual folders. In particular, the history ofpath mappings may include all virtual files accessed in a past period oftime. Since the cache does not have infinite storage, and to reducespeed and keep the cache consistent (e.g., if two different systemsaccess the virtual file), the history of objects can be time-based. Forexample, the history of path mappings can store which actual file(corresponding to the virtual file) was presented to the user first, or,which was displayed in the past.

For example, assume a physical file located in two different places. Auser opens the virtual drive (N:\), and based on keywords extracted fromuser activity, CXM services returns a virtual file corresponding to aphysical file located in e.g., Dropbox. While updating the physical file(opened via the virtual file), CXM services may continue searching forrelated files and return a virtual file corresponding to a differentphysical file, e.g., one located in Sharepoint. Thus, to maintainconsistency, the updates must be saved to the same physical file thatwas opened in the first place. The history of path mappings stores acontext by which such changes can be saved to the proper place.

Thus, the path mapping is a map which will relate the virtual file pathto the remote location path. For example, a virtual file might bedisplayed at the following path: N:/project1/report.docx (N:/ drivebeing the virtual drive), but may actually reside at the physicallocation www.dropbox.com/user/report“dot”docx. In such a case, the pathmapping would contain“V:/project1/report.docx→www.dropbox.com/user/report“dot”docx.”

Accordingly, using the history of path mappings, it is ordinarilypossible to keep cache 401 consistent with user actions. For example,when a request is received to open a selected file from a virtualfolder, the path of the selected file is resolved to a physical locationof a target file on a physical medium, by reference to an entry in therecorded history of path mappings corresponding to a time when the fileopen request was received. Then, the target file is opened from thephysical location on the physical medium. When a request is received toclose the opened file, the path of the opened file is resolved to aphysical location of a target file on a physical medium by reference tothe entry in the recorded history of path mappings corresponding to atime when the file open request was received, and the target file isclosed. In one aspect, closing the target file includes updating thetarget file with changes made to the opened file.

Specifically, when opening a file, the CXM file system driver 400receives a notification from the VFS local driver 406 that a file at avirtual path wants to be opened. This notification contains the path ofthe virtual file which must be opened. At this moment, the CXM filesystem driver 400 will look at the history of path mappings to find theremote path corresponding to that virtual file. Once the remote path isobtained, the CXM file system driver 400 will download the file in orderto display it to the user.

When closing a file, the CXM file system driver 400 receives anotification from the VFS local driver 406 that a file at a virtual pathneeds to be closed. That notification contains the path of the virtualfile which must be closed as well as the new data that needs to bewritten to that file. The CXM file system driver 400 will look at thehistory of path mappings to find the remote path corresponding to thatvirtual file. Once the remote path is obtained, the CXM file systemdriver 400 will write the new file data to said remote path.

In some aspects, changes to the virtual file are updated to the physicalfile via the mapping. For example, a request may be received to open aselected file listed in a virtual folder. The contents of the virtualfile are modified to add application-level attributes includinginformation for mapping of the virtual file to a physical location on aphysical medium, and the modified file is opened. In yet another exampleaspect, a request is received to close the opened file. Theapplication-level attributes added to the virtual file are extracted,including the physical path. The target file mapped by the path mappingis updated so as to include updates to the opened virtual file, and thevirtual file is closed.

Specifically, when changing a file, the CXM file system driver 400receives a notification from the VFS local driver 406 that a file at avirtual path needs to be saved. That notification contains the path ofthe virtual file which must be closed as well as the new data that needsto be written to that file. The CXM file system driver 400 will look atthe history of path mappings to find the remote path corresponding tothat virtual file. Once the remote path is obtained, the CXM file systemdriver 400 will write the new file data to the remote path.

Moreover, subsequent (i.e., second or later) searches for content by CXMservices can be controlled to manage how often the presented contentchanges. In that regard, in a context management system, suggestions orrelevant files and folders may change all the time. A consequence ofproviding a virtual file system with context-based search and retrieval(described more fully below) and indirect mapping is that, when contextchanges often (e.g., with multiple user actions), virtual files maydisappear from the view of the operating system often as they becomeless relevant, and may lead to a system crash if there is an attempt toaccess.

In contrast, according to the embodiments described herein, virtualfiles and folders may be maintained in cache 401 longer than they areexposed to the view of the operating system. For example, when anapplication is open, changes may happen all the time. Nevertheless, CXMfile system driver 400 may track, through VFS level driver 406, whenrequests from an application slow down or stop coming, and then discardthe virtual file afterwards. Requests to the file may then be blockeduntil the file is re-uploaded to cache 401. Or, a search by CXM servicesto update the virtual directory can be postponed.

On the other hand, searches may also be performed continuously andautomatically. For example, the subsequent (e.g., a second) search fornew files can be triggered by a change in current context of the user ofthe virtual file system that exceeds a predetermined threshold. Inanother example, the subsequent search can be triggered periodicallyafter an elapse of a predetermined interval. In still another example,the subsequent search can triggered by the first to occur of a change incurrent context of the user of the virtual file system that exceeds apredetermined threshold and an elapse of a predetermined interval.

For example, in one embodiment, receiving module 301 is responsible formonitoring the current context of a user. This current context is thefiles, folders, and applications opened by the user as well as theirZ-ordering (which one is in focus, which one is right behind it, etc. .. . ). A change score will be computed which marks how many things havechanged since the last search. For example, a switch in Z-order mayincrease the change score by 1, a new window opening may change it by 2,a window closing may change it by 3. Of course, these changes in scoreare simply examples, and changes can be scored or weighted as desired.When the change score reaches a configurable threshold, a new search ismade as the context is determined to have changed enough. When a newsearch is made, the change score is reset back to 0.

As mentioned above, repository connection services 402 performsdownload/upload operations on various local and remote repositories.Repositories can include cloud storage such as Google Drive, Amazon S3,Dropbox, etc., local file storage such as local drives, USB drive, etc.,and SharePoint and/or Network Shared drives/folders.

Upload services 403 monitors a queue of virtual files and/or virtualfolders to be uploaded (e.g., to update a virtual file which has becomestale), and pulls the necessary virtual files and/or virtual foldersfrom cache 401. In particular, when a physical file is modified, thecorresponding virtual file needs to be uploaded back to the cache 401.Not every change is pushed, however. In one embodiment, upload services403 may determine if the file is to be uploaded by checking if the lastaccess date of the cached item is older than a predetermined interval,such as based on a combination of the time taken to upload the file lasttime and the interval between each time the file is accessed by theoperating system. If it is determined that a file should be uploaded,upload services 403 may place a lock on the file (preventing allread/write/access), and then upload the file using repository connectionservices 402.

Mapper 404 resolves a relative path of the virtual drive to the actualpath pointing to a source physical document or directory. Since the rootdirectory lists documents and folders from different sources, mapper 404may utilize, e.g., a hash table to keep track of the history of pathmappings between virtual paths and the original source object, the hashtable/history of path mappings being stored in cache 401 as discussedabove. Mapper 404 also keeps a history of previous directory listings.In each directory listing, mapper 404 keeps track of all listed historyof path mappings and their corresponding destinations. When a request ismade to resolve a path to a non-root directory, mapper 404 looks at thehistory of path mappings (stored in cache 401) and locates the full pathfrom the virtual path.

Suggestion provider 405 acts as a layer of communication between CXMservices and, for example, an application driver which presents thevirtual file system to the user. CXM services, as mentioned above,searches for relevant files and folders based on actions of a user.Subsequently, suggestion provider 405 may provide a list ofdocuments/directories recommended for the user using CXM services. Inanother example, suggestion provider 405 may list relevant content. Forexample, given a full target folder path (local or remote), suggestionprovider 405 uses CXM services to provide a list of files and folders inthe target folder.

Virtual file system (VFS) level driver 406 is responsible for handlingoperating system requests. These include, file/folder open, read, write,seek, close, etc. Each incoming request from the operating system (e.g.,triggered by another application), includes identifying data about thevirtual file or folder being accessed (e.g. file name, desired access).

For example, if a directory listing is requested for a root folder, VFSlevel driver 406 uses suggestion provider 405 to retrieve new suggesteddocuments/folders for the root folder, and checks with mapper 404 to seeif it can resolve the paths to each document/folder. If the paths can beresolved, then the virtual file is retrieved from cache 401. If thepaths can not be resolved, VFS level driver 406 creates new virtualfile(s), and adds the virtual file to cache 401, and provides relevantinformation to mapper 404 (e.g., mapper 404 is informed that this is anew directory listing). An enumerable object for the virtual files (e.g,an enumeration ID) is generated to keep track of all enumerationrequests following this request.

If, on the other hand, a directory listing is requested for a non-rootfolder, VFS level driver 406 resolves the actual folder URL (e.g., theactual location of the file) using mapper 404, and uses suggestionprovider 405 to retrieve list of file/folders in that directory. Foreach file/folder retrieved, VFS level driver 406 checks if mapper 404can resolve the path. If the path can be resolved, then the virtual fileor folder is retrieved from the cache 401. If the path can not beresolved, VFS level driver 406 creates a new virtual file, and adds thevirtual file to cache 401, and provides relevant information to mapper404 (e.g., mapper 404 is informed that this is a new directory listing).An enumerable object for the virtual file (e.g., an enumeration ID) isgenerated to keep track of all enumeration requests following thisrequest.

Thus, the directory listing generated by CXM file system driver 400treats root directories of the virtual file system and sub-directoriesof the root directory differently. In particular, the root directory ofa virtual file system is used to provide suggestions of virtual files orfolders, whereas a non-root directory may map to the actual physicaldirectory where the files are stored.

VFS level driver 406 also provides read, write and seek operations onvirtual files. As mentioned above, VFS level driver 406 may resolve anactual file URL (the location of a source file) using mapper 404. Usingthe URL, VFS level driver 406 may look for instances of the virtual fileor folder in cache 401. As mentioned above, VFS level driver 406 maycreate a new virtual file or folder if the sought-after virtual file orfolder cannot be located.

In a read operation, VFS level driver 406 adds the requested virtualitems (virtual files or folders) to cache 401, uses repositoryconnection services 402 to update (write to) the cache 401(asynchronously), and completes the read request as soon as a data chunkof the virtual file or folder is available.

In a seek operation, VFS level driver 406 adds the requested virtualitems (virtual files or folders) to cache 401, uses repositoryconnection services 402 to update (write to) the cache 401(asynchronously), and completes the seek request as soon as a data chunkof the virtual file or folder is available.

In a write operation, VFS level driver 406 seeks to the right address(if needed), writes the data to cache 401, uses upload services 403 toqueue modifications for upload, and cache 401 is updated to reflect thelast access date of the updated item.

VFS level driver 406 also manages virtual file attributes andproperties. For example, VFS level driver 406 resolves an actual fileURL using mapper 404, looks for instances of the virtual file or virtualfolder in cache 401, pulls file properties, generate and adds attributes(e.g., Original Document Path, Author, etc), and provides thisinformation to the operating system.

VFS level driver 406 also provides cleanup services. Specifically, filesthat have been closed by the operating system, are not accessed for sometime, and have already been uploaded (in the case of modified filesonly), are automatically removed from cache 401 and mapper 404. In thisregard, an operating system may tend to close and re-open files often,therefore, a specified, minimum time is given before the cleanup occurs.This improves conditions where the operating system may attempt toaccess a file after it has closed it (and requested cleanup).

In addition, if an operating system requests a directory list or filesor search folder requests as part of a previous listing (the operatingsystem can make multiple requests for directory listing, each timerequesting either a single file with a specified name and extension or acontinuation of a previous enumeration/listing), the VFS level driver406 locates the enumerable files for the listing using an enumeration,returns the objects, and increments the enumeration.

FIG. 5A is a flow diagram for explaining a CXM system (e.g., CXMservices, VFS level driver, sharepoint services, etc.) according to anexample embodiment. In that regard, VFS level driver monitors systemstate and user behavior correlated over time, and CXM services performcontext collection. For example, VFS level driver 406 monitors whichapplications are open, titles of open windows a files, what filesapplications are accessing, and so on. VFS level driver 406 can thendetermine which are being accessed the most, and can extract keywordsrelated to those applications/files/etc. to send as a query to a CXMservice, which returns with files and/or related folders. Thus, the CXMservice is how relevant documents to user actions are automaticallyobtained and provided to the user.

Thus, in step 501, a user saves a file to their local hard drive relatedto “Task A”. In step 502, the virtual drive (e.g., via VFS level driver406) creates a folder named “Task A” corresponding to the user task. Instep 503, a contextual search of all repositories on the network (e.g.,including other computers on network 300) is performed using the CXMsystem. In step 504, files resulting from the CXM system search areadded to the virtual drive.

Meanwhile, as mentioned above, searching for files and folders relatedto the current context can be performed continuously and automatically.Thus, the process proceeds to step 505, where a change in user contextor an elapse of time is detected, and to step 506, where the context isupdated. Thus, searching is updated based on a time-wise change incontext. The process then returns to step 503 to continue the automaticcontext search.

FIG. 5B is a view for illustrating a process for adding one or morefiles to a virtual drive.

As shown in FIG. 5B, a user may open a Microsoft Word document 552(spec.doc) from a local drive 551A (C:\Desktop) and save it to thedesktop. The virtual drive system creates a folder 557 for this documentin the virtual drive 558, and stores the document 552 in the folder 557.A contextual search using the contents of the document 552 and usercontext is performed using the CXM system, and files resulting from theCXM system search are added to to folder 557. Thus, as shown in FIG. 5B,document 554 (CXM-12/spec/biblio.doc) from SharePoint drive 553A anddocument 556 (P:/CXM/docs/spec/diagrams.doc) from ShareFolders 555A areretrieved and added to folder 557.

FIG. 6, comprising FIG. 6A and FIG. 6B, is a block diagram illustratingan example system architecture for a virtual file system according to anexample embodiment.

In that regard, cache 401, repository connection services 402, uploadservices 403, mapper 404 (not shown), suggestion provider 405 and VFSlevel driver 406 are discussed above with respect to FIG. 4, and forpurposes of conciseness that description is not repeated in full herein.As mentioned above, repository connection services 402 is component(s)that provides list/download/upload access to various repositories orother CXM components that can provide such functionality, and suggestionprovider 405 is connection service to the CXM engine that can provides alist of suggested documents and folders. Suggestion provider 405 alsoreceives keywords from the CXM Engine, which it sends to the searchservice provider to receive recommendations from a variety of services(e.g., remote search endpoints 604, local service search provider 602).

Recent document/directory crawler 600 receives input from a clientapplication, such as recent documents and directories opened or accessedby the user. The goal of recent document/directory crawler 600 is tounderstand and index all recent documents/directories a user has workedwith. This list of documents/directories is provided by the OS. Whilecrawling, the title of a document as well as some text extracted fromthe document will be stored in said index.

This index is then searched by the client application 650, using asinput the keywords generated by the suggestion provider 405, whichreturns suggestions and keywords it used to retrieve suggestions. Using,for example, virtual file system (VFS) level driver 406, thisinformation can be added to the cache 620 in the form of metadata.

In that regard, cache 620 is not necessarily the same cache as cache401. In particular, cache 620 is a recent document/directory metadatacache. The goal of cache 620 is to save the information collected fromthe recent document/directory crawler 600 and make it easily searchable.Cache 620 saves, e.g., the title of a document, some text extracted froma document, as well as additional metadata. Local service searchprovider 602 can then query it in order to get suggestions from recentdocuments. In one aspect, cache 620 can be helpful in situations where,e.g., recent documents may not all be indexed by the Windows Search andIndexing Service, but can still be very valuable (i.e., when Windowsdoes not index all files).

Windows search and indexing service 601 provides information to thecache 401 acquired when the local service search provider 602 queriesthe Windows search and indexing service 601. In particular, windowssearch and indexing service 601 is a component built into MicrosoftWindows, and powers local search on a computer. In order to search notonly remote repositories but also the local drive, local service searchprovider 602 will query windows search and indexing service 601 withkeywords obtained by local service search provider 602. This will thenreturn local documents relevant to the user's context.

Local service search provider 602 is a component which searches bothrecent documents accessed by a user on the computer/device, as well asdocuments indexed by the windows search and indexing service 601. Localservice search provider 602 is responsible for merging these results andordering them by relevance.

Crawler services 603 is a set of application program interfaces (APIs)exposed by the recent document/directory crawler 600 which allows a userto gain additional information regarding a folder. Thus, if arecommendation is close, a user can see surrounding files.

Remote search endpoints 604 allow the clients to search various datasources using the keywords generated by CXM. For example, keywords canbe used to search Google or StackOverflow, and bring relevant web pagesas results.

Web service provider 605 is a layer which abstracts out the crawlerservices 603 and remote search endpoints 604. Web service provider 605can handle multiple remote search endpoints as well as crawler services,and can convert results into a unified format.

Search service provider 606 provides a simple way for the suggestionprovider 405 to query multiple services (e.g., remote search endpoints604, local service search provider 602) and to receive results in astandard format. Thus, suggestion provider 405 uses the information insearch service provider 606 to provide a suggestion to the clientapplication 650.

As mentioned above, repository connection services 402 is component(s)that provides list/download/upload access to various repositories orother CXM components that can provide such functionality, and suggestionprovider 405 is connection service to the CXM engine that can provides alist of suggested documents and folders. Suggestion provider 405 alsoreceives keywords from the CXM Engine, which it sends to the searchservice provider to receive recommendations from a variety of services(e.g., remote search endpoints 604, local service search provider 602).

Windows client sidebar 608 is a sidebar which allows a user to easilyget results related to their context with a simple shortcut. It alsoprovides relevant documents to a user's context, but is used differentlythan the virtual file system as it is quicker to get to.

Upload services 403 may upload changes or updates to the files. Downloadservices 607 allow any file to be downloaded (for example, to be opened)from any of the repositories connected to the repository connectionservices 402.

Local file system services 551B is a plugin for the repositoryconnection services 402 which can allow for downloading/uploading filesto the local file system. SharePoint services 553B is a plugin for therepository connection services 402 which can allow fordownloading/uploading files to SharePoint. Shared folder services 555Bis a plugin for the repository connection services 402 which can allowfor downloading/uploading files to shared folders.

A more detailed version of the virtual drive (N:\) shown in FIG. 1 isdepicted in application interface 610. Application 611 (App 1),application 612 (App 2), and so on, to application 613 (App n) areapplications which are accessed or manipulated by a user. Windows kernel614 enable the application interface 610 to interact with hardwaredevices, and dokan device driver 615 is a Windows user mode file systemwhich works as a proxy and acts like a “pipe” to pass information from adevice to a protected portion of a file system (e.g., an OS kernel). Asshown in FIG. 6, dokan device driver 615 passes device input to VFSlevel driver 406. More specifically, dokan device driver 615 includes alibrary which contains a user mode dynamic-linked library (DLL) and akernel mode file system driver. Once dokan device driver 615 isinstalled, file systems for devices can be created which are seen asnormal file systems in, e.g., Windows. CXM crawler services 609 mayprovide additional services for obtaining relevant documents from otherrepositories not shown in FIG. 6.

FIG. 7 is a flow diagram for explaining access to root and non-rootdirectories according to an example embodiment.

Briefly, in FIG. 7, results are received of a first search for filesrelated to a current context of a user of the virtual file system, thefiles being stored on physical media and/or other virtual file systems.The results of the first search are organized into contextuallysignificant virtual folders in the virtual file system. Responsive toselection of a virtual folder in the virtual file system, a list offiles organized in the selected virtual folder according to the firstsearch is displayed. Responsive to selection of a root directory in thevirtual file system, results are obtained of a second search for filesrelated to an updated context of the user of the virtual file system,the organization of contextually significant virtual folders is updated,and the updated organization of virtual folders is displayed.

In more detail, in step 701, based on user input obtained via windowsapplication 611, windows kernel 614 and dokan device driver 615, the CXMservices perform a first search for files related to a current contextof a user of the virtual file system, the files being stored on physicalmedia and/or other virtual file systems. The results of the first searchare organized into contextually significant virtual folders in thevirtual file system.

In step 704, there is a determination of whether a selected folder is aroot folder. The root of the drive may always be the first suggestionreturned by CXM services. If the selected directory is not a rootdirectory, then the process proceeds to step 702, whereas if theselected directory is a root directory, the process proceeds to step705.

In step 702, responsive to selection of a virtual folder in the virtualfile system (e.g., not the root folder), a list of files organized inthe selected virtual folder according to the first search is displayed.In particular, the file and folder of the remote directory storing thephysical file are obtained via the history of path mappings stored incache 401, and there is a connection to the CXM crawler 609 in step 703to get the directory listing. The process proceeds to step 708, wherethe file/folder metadata for a corresponding virtual file is generatedusing available metadata in the CXM system. In step 709, the pathmapping between the actual remote file/folder object (the physical file)and the virtual file/folder path and metadata is created or updated, andstored in cache 401.

Returning to step 702, responsive to selection of a root directory,results are obtained of a second search for files related to an updatedcontext of the user of the virtual file system, the organization ofcontextually significant virtual folders is updated, and the updatedorganization of virtual folders is displayed.

In more detail, in step 705, suggestions are obtained from user actionsand context. In particular, as mentioned above, VFS level driver 406monitors which applications are open, titles of open windows a files,what files applications are accessing, and so on. VFS level driver 406can then determine which are being accessed the most, and can extractkeywords related to those applications/files/etc.to send as a query toCXM services.

Thus, in step 706, a search query is generated using, for example,system behavior and state/monitoring information obtained by VFS leveldriver 406 via, for example, a windows client, and in step 707, there isa connection to CXM services to get suggestions from, for example, CXMcrawler services 609. The process proceeds to step 708, where thefile/folder metadata for the virtual files or folders is generated usingavailable metadata in the CXM system. In step 709, the path mappingbetween the actual remote file/folder object (the physical file) and thevirtual file/folder path and metadata is created or updated, and storedin cache 401.

FIG. 8 is a flow diagram for explaining a virtual file system dataaccess/read flow according to an example embodiment.

In step 801, the requested operation (read/access/etc.) is determinedbased on user input obtained via windows application 611, windows kernel614 and dokan device driver 615. In step 802, there is a determinationof whether the user is done with the file. If not, the process proceedsto step 803.

In step 803, a requested fragment of a file is identified, and in step804, there is an attempt to locate the target file object by consultingcache 401. In step 805, there is a determination of whether the file iscached. If so, the process proceeds to step 806 to read the targetfragment from the cache 401, and the process returns to wait for furtheruser input. If the file is not cached, the file is downloaded from anexternal source via download services 607 and stored in the cache 401.

If, on the other hand, the user is determined to be done with the filein step 802, the process proceeds to step 807, where a cleanup processis performed on cache 401. Specifically, the cleanup process discardsold files in the cache, as discussed above with respect to FIG. 4.

FIG. 9 is a flow diagram for explaining a virtual file system dataaccess/write flow according to an example embodiment.

In step 901, the requested operation (read/access/etc.) is determinedbased on user input obtained via windows application 611, windows kernel614 and dokan device driver 615. In step 902, there is a determinationof whether the user is done with the file. If not, the process proceedsto step 903.

In step 903, the requested fragment of the file is identified, and instep 904, there is an attempt to locate the target file object byconsulting cache 401. In step 905, there is a determination of whetherthe file is cached. If so, the process proceeds to step 906 to write thetarget fragment to the cache 401, and the process returns to wait forfurther user input. If the file is not cached, the file is downloaded instep 909 from an external source via download services 907 and stored inthe cache 401.

If, on the other hand, the user is determined to be done with the filein step 902, the written (e.g. updated) file is written back to theoriginal physical location in step 907 via upload services 403, and theprocess proceeds to step 908 to cleanup the cache 401.

Other Embodiments

According to other embodiments contemplated by the present disclosure,example embodiments may include a computer processor such as a singlecore or multi-core central processing unit (CPU) or micro-processingunit (MPU), which is constructed to realize the functionality describedabove. The computer processor might be incorporated in a stand-aloneapparatus or in a multi-component apparatus, or might comprise multiplecomputer processors which are constructed to work together to realizesuch functionality. The computer processor or processors execute acomputer-executable program (sometimes referred to ascomputer-executable instructions or computer-executable code) to performsome or all of the above-described functions. The computer-executableprogram may be pre-stored in the computer processor(s), or the computerprocessor(s) may be functionally connected for access to anon-transitory computer-readable storage medium on which thecomputer-executable program or program steps are stored. For thesepurposes, access to the non-transitory computer-readable storage mediummay be a local access such as by access via a local memory busstructure, or may be a remote access such as by access via a wired orwireless network or Internet. The computer processor(s) may thereafterbe operated to execute the computer-executable program or program stepsto perform functions of the above-described embodiments.

According to still further embodiments contemplated by the presentdisclosure, example embodiments may include methods in which thefunctionality described above is performed by a computer processor suchas a single core or multi-core central processing unit (CPU) ormicro-processing unit (MPU). As explained above, the computer processormight be incorporated in a stand-alone apparatus or in a multi-componentapparatus, or might comprise multiple computer processors which worktogether to perform such functionality. The computer processor orprocessors execute a computer-executable program (sometimes referred toas computer-executable instructions or computer-executable code) toperform some or all of the above-described functions. Thecomputer-executable program may be pre-stored in the computerprocessor(s), or the computer processor(s) may be functionally connectedfor access to a non-transitory computer-readable storage medium on whichthe computer-executable program or program steps are stored. Access tothe non-transitory computer-readable storage medium may form part of themethod of the embodiment. For these purposes, access to thenon-transitory computer-readable storage medium may be a local accesssuch as by access via a local memory bus structure, or may be a remoteaccess such as by access via a wired or wireless network or Internet.The computer processor(s) is/are thereafter operated to execute thecomputer-executable program or program steps to perform functions of theabove-described embodiments.

The non-transitory computer-readable storage medium on which acomputer-executable program or program steps are stored may be any of awide variety of tangible storage devices which are constructed toretrievably store data, including, for example, any of a flexible disk(floppy disk), a hard disk, an optical disk, a magneto-optical disk, acompact disc (CD), a digital versatile disc (DVD), micro-drive, a readonly memory (ROM), random access memory (RAM), erasable programmableread only memory (EPROM), electrically erasable programmable read onlymemory (EEPROM), dynamic random access memory (DRAM), video RAM (VRAM),a magnetic tape or card, optical card, nanosystem, molecular memoryintegrated circuit, redundant array of independent disks (RAID), anonvolatile memory card, a flash memory device, a storage of distributedcomputing systems and the like. The storage medium may be a functionexpansion unit removably inserted in and/or remotely accessed by theapparatus or system for use with the computer processor(s).

This disclosure has provided a detailed description with respect toparticular representative embodiments. It is understood that the scopeof the appended claims is not limited to the above-described embodimentsand that various changes and modifications may be made without departingfrom the scope of the claims.

What is claimed is:
 1. A method for a virtual file system executed by a computer, wherein the virtual file system simulates physical files stored on other repositories of other computers as files which are accessible locally for a user, the method comprising: receiving a request for a file operation to a file in the virtual file system from an application interface on a hardware device of a computer via a proxy driver; performing, by a context management system driver different from an application including the application interface, a context management service in response to a reception of the request, wherein the context management service of the context management system driver includes: receiving results of a first search for files related to current context of the user, organizing the results of the first search into a virtual folder of the virtual file system, recording entries into a history of path mappings, wherein the path mappings map a location of the virtual folder to locations of the files, corresponding to the result of the first search, and wherein the history of path mappings is recorded onto physical media, determining whether the virtual folder is or is not a root, further receiving, responsive to a determination that the virtual folder is a root, a result of a second search for files related to another current context, the files being stored on a repository of physical media of said other computers connected with the virtual file system, updating the result of the second search into the virtual folder related to the result of the first search, and further recording entries into the history of path mappings which map the location of the virtual folder to locations of the files, corresponding to the result of the second search, on the physical media.
 2. The method according to claim 1, further comprising: monitoring the current context including at least user behavior correlated over time, wherein the second search is performed based on the updated current context of the user according to the monitoring.
 3. The method according to claim 2, wherein the monitoring is performed based on keywords related to an application being used by the user and text information of a file accessed by the application.
 4. The method according to claim 1, further comprising: resolving a path of the selected file to a physical location on the repository of the physical media by reference to an entry recoded in the history of the path mappings corresponding to a time when the file operation request was received. 